feat(wallet): actually run the federation server stellar.toml advertises - #1330

`public/.well-known/stellar.toml` has been publishing

    FEDERATION_SERVER = "https://app.useveilapp.xyz/api/federation"

to anyone who looked, while that route did not exist. Every attempt to resolve
a Veil name got Next's HTML 404 where a wallet expected JSON, so Veil was
naming a federation server it did not run. The repo's own comment in the toml
admitted the URL was aspirational — but the file is deployed.

Adds the SEP-2 endpoint and the resolver behind it:

- `type=name` reads `resolve(name)` off `contracts/veil-names`. Expiry needs
  no handling: the contract already returns `None` past it, which is what
  makes a lapsed name stop resolving instead of quietly paying whoever buys it
  next.
- `type=id` answers 404 by design. The registry is keyed name -> address with
  no reverse index, so answering would mean scanning every name.
  `lib/reverseResolution.ts` already degrades to null and renders the raw
  address.
- `type=forward` is a 400, not a 404. The spec reserves it for handing a
  payment to an off-network rail and Veil runs none, so "not found" would
  imply a right destination might exist.
- `type=txid` is a 404.

The registry contract is not deployed, so every lookup is a truthful 404
today. The shape is the point: a wallet that handles this endpoint now keeps
working the moment the registry is live, and nothing here invents an answer.
`getNamesContractId()` has deliberately no baked-in default, unlike the
factory id, because a placeholder would make the module speak with confidence
about a contract that does not exist.

Two deliberate choices worth stating:

- Names are shape-checked here against `validate_shape` in the contract before
  any RPC. It is a short-circuit, not a control — the contract re-checks,
  because anyone can invoke it directly — but it keeps a junk query from
  costing a metered QuickNode call. A Cyrillic homoglyph is refused rather
  than folded to ASCII; folding would let one name resolve to another holder's
  payment destination.
- An RPC failure resolves to a 404, never a 500. `lib/federation.ts`
  distinguishes 404 ("address not found") from anything else ("server
  unreachable"), and a server that 500s on a hiccup teaches callers both that
  the name does not resolve and that Veil is unreliable. Only the first is
  true.

⚠ Recorded in the module header rather than fixed: a Veil name resolves to a
`C…` address, and SEP-2 documents `account_id` as a Stellar public key. A
classic `payment` cannot address a contract, and CAP-84 `W…` addresses do not
help because a muxed contract address is not a classic destination either. So
a Veil name is payable from Veil and from anything speaking Soroban, and not
from an exchange. Returning the contract address is still right — that is
where the money is, and inventing a `G…` would be worse — but it has to be
settled before a name is marketed as an address you can give anyone. See
docs/IDENTIFIER_ADDRESSES.md.

`npx tsc --noEmit` clean; 32 new tests.

Claude-Session: https://claude.ai/code/session_01USgemLt4Rnz4SGB1Srf3GB